docs(adr-013): Erratum E3 — lift the pipeline_core_version caveat, in part - #237
Merged
Polichinel merged 1 commit intoAug 10, 2026
Merged
Conversation
… part #228 asked for this: §2.2 declared the field unreliable until pipeline-core cut a real release, and 3.0.0 shipped to PyPI on 2026-08-03. Condition met. But the lift is narrower than the request's suggested wording, and the difference is a released-versus-merged distinction worth getting right. authoritative when the producer ran a RELEASED distribution — a wheel's recorded version is written by the release that built it, so it cannot disagree with the code beside it. In force now. "unknown" when the producer ran an EDITABLE install — NOT yet in any released version. pipeline-core#403 makes that case report "unknown" instead of a stale number, and it merged 2026-08-04 13:58, a day and a half AFTER 3.0.0 was uploaded (2026-08-03 02:06). #228's suggested note states this half as current; it is not, and becomes true at pipeline-core's next release. Verified here rather than taken on trust: in this repo's environment importlib.metadata reports pipeline-core 2.3.0 while the source beside it is 3.0.0 — a full major version stale, exactly the value that would have been stamped into published provenance. With the fix present, _pipeline_core_version() returns "unknown". The operational point, which #228 got right: consumers must treat "unknown" as "do not infer the producing version", never as an error — and the set producing it will WIDEN at the next release, because every developer run joins it. Nothing in this repository changes. Hop-B re-embeds the Hop-A header untouched, so we forward this value and never compose it. contract_version stays 1.5. E3's claim that the fix is unreleased will expire, so it carries a check: test_e3s_claim_about_unreleased_behaviour_is_still_true fails if the installed pipeline-core is a released distribution past 3.0.0. Inert in an editable environment and live in CI, which installs from PyPI — stated in the docstring rather than left to be discovered. Mutation-proven against a synthetic 3.1.0 wheel. Suite 399 passed / 1 skipped / 40 xfailed; ruff clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #228, with one correction to what it asked for.
What #228 asked
§2.2 declared
pipeline_core_versionunreliable until pipeline-core cut a real release. 3.0.0 shipped to PyPI on 2026-08-03, so the condition is met. Lift the caveat.Agreed — but the suggested wording states one half as current when it is not.
The correction: released versus merged
pipeline_core_version"unknown"pipeline-core#403 makes the editable case report
"unknown"rather than a stale number. It merged 2026-08-04 13:58. 3.0.0 was uploaded 2026-08-03 02:06 — a day and a half earlier. So the fix is on pipeline-core'smainand in no release. It becomes true of producers at their next one.#228's suggested note reads as though both halves are live. E3 says which is which.
Verified here, not taken on trust
A full major version stale — exactly the value that would have been stamped into published provenance, and exactly what the fix suppresses.
The operational point, which #228 got right
Consumers must treat
"unknown"as "do not infer the producing version", never as an error — and the set of runs producing it will widen at pipeline-core's next release, because every developer run joins it. A consumer that starts rejecting"unknown"on the strength of this lift breaks exactly those runs.Nothing in this repository changes
Hop-B re-embeds the Hop-A header untouched, so we forward this value and never compose it.
contract_versionstays 1.5.The claim carries a check, because it expires
E3 says the fix is unreleased. That stops being true the day pipeline-core publishes again, and nothing here would signal it.
test_e3s_claim_about_unreleased_behaviour_is_still_truefails if the installed pipeline-core is a released distribution past 3.0.0. Inert in a maintainer's editable environment, live in CI which installs from PyPI — stated in the docstring rather than left to be discovered, since a guard that only runs in one place is half a guard. Mutation-proven against a synthetic 3.1.0 wheel.Downstream
#228 notes views-faoapi is the other reader of this field and inherits both halves. Worth a note to them; not done in this PR.
🤖 Generated with Claude Code